J 



Europaisches Patentamt 

European Patent Off ice @ Publication number: 0 072 183 

Office europgen des brevets A2 



© EUROPEAN PATENT APPLICATION 

® Application number: 82304091.0 ® Int. CI. 3 : G 06 F 15/30 

© Date of filing: 03.08.82 



@> Priority: 05.08.81 US 290029 


© 


Applicant: NCR CANADA LTD - NCR CANADA LTEE, 
6865 Century Avenue, Mississauga Ontario, 
L5N2E2(CA) 


© Date of publication of application : 16.02.83 
Bulletin 83/7 




Inventor: Rushby, Robert John, 608 Glen Forrest, 
Waterloo Ontario N2L3J8 (CA) 
Inventor: Damms, Anthony Bryan, 333 Country Hills 
Drive, Kitchener Ontario N2E 2C1 (CA) 


@ Designated Contracting States : DE FR GB 


® 


Representative: Robinson, Robert George, International 
Patent Department NCR Limited 206 Marylebone Road, 
London NW16LY(GB) 



CI 

< 

o 

09 

CI 
N 
O 

o 

a 
111 



@ System and method for processing financial transactions. 

@ A system for improving the processing of financial trans- 
actions using direct customer entry of the transaction data and 
automatic verification of this data during proof operations. 
Each customer (8) prepares his own transaction slip (24) via a 
remote terminal (10), which slip is delivered to a teller (46) for 
verification. During proof and encoding operations, the amount 
field of each document (44) is read and compared with the data 
entered by the customer for correspondence; any errors may 
be corrected at this stage for reconciliation, saving time and la- 
bour costs. 
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System and Method for Processing 
Financial Transactions 

Technical Field 

This invention relates generally to a system for pro- 
cessing financial transactions and, in particular, to a system for 
efficiently and reliably completing a banking transaction in which 
the customer directly enters financial information at a remote 
terminal unit. 

Background Art 

Financial institutions are constantly striving to improve 
the quality of their services, but without incurring any additional 
expenses to provide these improved services. Thus, in order to 
be marketable, any new system must be cost-effective; the pro- 
cessing cost per item must be lower than current systems when 
comparing the same processing functions and volumes. These 
costs can be broken down into the following categories: capital 
costs and operating costs. In the financial industry, a major 
portion of the operating costs is expended in the area of teller 
operations, data entry and proof operations, and error reconcili- 
ation. 

Disclosure of the Invention 

It is therefore an object of the present invention to 
provide a system and method which improve accuracy and speed 
in processing financial transactions, while achieving an overall 
reduction in processing cost per item and which simplify and 
minimize the office work required for transactions, in particular, 
verifying and proving transactions at a bank, thereby reducing 
labour costs. 

Thus, according to the invention, there is provided 
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a system for processing financial transactions, characterized by 
first processing means; first terminal means, coupled to said 
first processing means, for permitting a customer to enter into 
said first processing means information concerning a financial 
transaction; second terminal means, coupled to said first pro- 
cessing means for enabling a teller to verify said customer- 
entered information; and first storage means, coupled to said 
first processing means, for storing said customer- entered 
information subsequent to said teller verification. 

According to another aspect of the invention, there 
is provided a method for processing financial transactions within 
a bank, characterized by the steps of enabling a customer to 
enter into a first processing means information concerning a 
financial transaction through the use of a first terminal means; 
enabling a teller to verify and, if necessary, correct the 
customer-entered information by use of a second terminal means; 
and permanently storing within a first storage means said customer- 
entered information subsequent to teller verification. 

The system and method of the present invention are 
usefel in a novel bankSng scheme in which each customer prepares 
liis own transaction slfps using a customer-accessed terminal. 
The customer enters 3ie totals from each item to be processed 
into the terminal, and a machine- readable identification is imprinted 
thereon. The terminal automatically provides a printed deposit 
slip at the completion of the transaction, which slip is given to 
a teller for verification via a terminal located at the teller 
station. The teller has only to verify the endorsements and 
amounts entered. Any inconsistencies are corrected at this time, 
and the transactions may be considered proven. When these 
items are processed during the proof operation, they may be 
identified by the machine- readable code, and all data concerning 
each transaction may be accessed from a processor using this 
code, which data is useful in verifying and proving all transactions. 
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Brief Description of the Drawings 

One embodiment of the invention will now be described, 
by way of example, with reference to the accompanying drawings, 
in which: 

5 Fig. 1 is a schematic block diagram of the system 

embodying the present invention; 

Fig. 2 is a diagrammatic representation of the remote 
terminal which is employed in the present invention; 

Fig. 3 is a diagrammatic representation of the front 
10 of a bank check. 

Best Mode of Carrying Out the Invention 

Referring now to Fig. 1, there is shown a block 
diagram of a preferred embodiment of the system disclosed in 
the present invention. A customer 8 proceeds to one of a series 
15 of customer terminals 10 situated in a convenient location, such 
as the lobby, within the financial institution. Terminal 10 is 
used by each customer to prepare a deposit slip by keying in 
the amount data for all documents. 
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Referring now to Fig. 2, there is shown a 
customer keying terminal 10 which may be used in con- 
nection with the present invention. In one mode of 
operation, the customer may identify himself at terminal 
10 by entering a secret personal identification number 
assigned to him by the financial institution via a 
keyboard 12. Alternatively, a card bearing a magnetic 
stripe (not shown) may be used to identify the customer 
at terminal 10. 

When terminal 10 has confirmed the identity of 
the customer, the terminal displays an image representing 
a deposit slip upon a cathode ray tube (CRT) screen 14. 
A chart 16 displays a series of lead-through instructions 
for assisting the customer in completing the sequence 
for generating his deposit slip. A set of control keys 
generally indicated by the numerical designation 18 
are used for controlling operation of the transaction 
entry process. 

To begin generation of a deposit slip, the 
customer first enters his personal account number via 
keyboard 12, and loads this information into terminal 10 
by depressing the ENTER key 18. He next enters via 
keyboard 12 the amount on the first document he wishes 
to deposit. After the amount is entered and displayed 
on CRT screen 14, the customer inserts the document into 
a printer module 20, and depresses the ENTER key 18, 
causing printer module 20 to operate. As each document 
is transported into printing relationship within module 
20, a document identification number (DIN) is printed in 
bar code form on the reverse side of the document, 
while a human-readable amount corresponding to the 
amount entered on keyboard 12 is printed on the front 
side. The customer then removes the document from a 
receptacle 21 of module 20. The customer repeats the 
above sequence for each of the documents 42 that he wishes 
to deposit. 
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As the bar-weed DIN is being printed on each 
document to positively identify it, a data file is 
created which relates that particular document to its 
bar code. This data is transmitted from customer ter- 

5 minal 10 via a data link to a branch control or "front 
office" processor 45 (Fig. 1). All of the customer 
terminals 10 are coupled in parallel to processor 45. 

If the customer wishes to receive any cash in 
the transaction he enters the desired amount via key- 

10 board 12 into terminal 10 after he has processed all 
deposit documents. He then depresses the CASH key of 
control keys 18 , which causes a cash out slip (not 
shown) to be printed at a receipt printer module 22 , 
which slip is encoded with a bar code on the reverse 

15 side. 

After all keying is complete, the customer 
depresses the TOTAL key 18, causing terminal 10 to 
total the complete transaction, with the resulting 
figures displayed on CRT screen 14. If the displayed 

20 totals are agreeable to the customer, he depresses the 

COMPLETE key 18, causing a deposit slip 24 to be printed 
at receipt printer module 22 for the customer, which 
slip is also bar-coded and contains the customer account 
number. At this time, terminal 10 stores the details of 

25 the transact ion, including amounts, bar codes, and 

customer information, in the data file within processor 
45. The customer removes deposit slip 24 from printer 
module 22, and proceeds to the teller window. A dupli- 
cate of deposit slip 24 for the customer's personal 

30 records may be obtained by depressing the DUPL key 18. 

Referring again to Fig. 1, at the time the 
customer appears at the teller window, he presents the 
bank documents, which have previously been encoded at 
terminal 10, along with completed deposit slip 24 and 

35 any cash out slips (which group of documents comprise a 
transaction 44) to a teller 46. Teller 46 checks every 
document contained in the transaction to determine that 
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each amount has been correctly entered , that all items 
entered on the deposit slip are present, and that all 
necessary signatures are present. Any errors that teller 
46 detects are corrected via a terminal 48 at the teller 

5 window. Terminal 48 is coupled on-line to processor 
45 r as are the customer terminals 10. Teller 46 can 
access the data file associated with a transaction 
within processor 45 by keying in the customer account 
number. The data will appear on a CRT screen at teller 

10 terminal 48 / and teller 46 may correct any errors via 

keyboard entry. When teller 46 has determined that all 
steps of the transaction have been completed correctly, 
he depresses an entry key on teller terminal 48 which 
allows the data associated with the transaction to be 

15 permanently stored within processor 45. 

At this stage, the system may consider all 
transactions as proven. Physical control (by DIN) has 
been established, and the only errors which can occur 
from this point on are misplaced items. In addition, it 

20 should be noted that the teller has less work to do than 
under the current system, as no checking of calculations 
is required. 

An in-balance data file has now been created 
on a transaction level; during the course of the 

25 business day, the teller accumulates transactions into a 
batch file 60. Batch file 60 should always be in 
balance; that is, the debits will always equal the 
credits. Batch file 60 is then stored on a permanent 
memory device 61 such as a cartridge or disc at the 

30 processor in the branch or "front office" processor 45. 

Documents accumulated during the course of the 
business day are physically taken in batches to the bank 
processing center to be processed. The data file which 
was created at branch control processor 45 is also 

35 transmitted to the bank processing center. This data 
file may be transferred physically by tape cassette or 
floppy disk (permanent memory 61), or processor 45 may 
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be linked directly on-line to the processing center. A 
proof control or "back office" processor 62 located at 
the bank processing center receives the data file from 
the branch control processor 45. In financial insti- 

5 tutions which use completely centralized processing 

systems, proof control processor 6 2 and branch control 
processor 45 may be replaced by a single central pro- 
cessor. In the present embodiment, the "back office" 
proof control processor 62 is file-driven, using the bar 

10 code to identify each document and relate it to the 

previously captured data which was permanently stored 
in memory 61 and subsequently stored within the pro- 
cessor. 

Each document contained in batch 60 is sub- 

15 sequently passed through a document transport 66 for 

proof and encoding operations which transport includes a 
bar code reader 66a, a MICR or OCR reader 66b, an 
imaging device 66c, and a verification unit 66d. As 
each document is conveyed through transport 66, the bar 

20 code is read from the document by reader 66a, allowing 

processor 62 to associate the document with the customer- 
entered information within the data file created pre- 
viously. Reader 6 6b then reads the MICR information 
which is printed on the face of the check. The document 

25 image is digitized by imaging device 66c and then trans- 
mitted to an image file 69, which is coupled to a cour- 
tesy amount verification processor (or image control 
processor) 70. 

The concept of courtesy amount verification 

30 may be defined as the process of verifying through 

optical character recognition techniques that an amount 
that is presumed to be written on a document is indeed 
present. The courtesy amount on a bank check is the 
amount written as numeric characters, as opposed to the 

35 legal amount, which is written out in alphabetic char- 
acters. Fig. 3 shows a diagrammatic representation of a 
bank check containing both the legal amount and courtesy 
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amount. The legal amount is designated as 71 , while the 
courtesy amount is designated as 72. 

Courtesy amount verification techniques can 
also be used in other applications where there is a need 
to verify that expected data is correct. Courtesy 
amount verification provides the following useful char- 
acteristic to the system of the present invention; it is 
much simpler to compare each character of a previously 
known amount with characters found on an image in order 
to verify that these characters are present , as compared 
to identifying a totally unknown amount on a document; 
this is true because the recognition equipment need only 
compare the read character features with a single known 
character for each digit, rather than compare each read 
character with a larger set of possible character 
features. Thus, the misread rate of the system becomes 
less important. 

The courtesy amount verification processor 70 
locates and isolates the numerals comprising the cour- 
tesy amount data on the document. This may be achieved 
by using either pre-defined coordinates on the document, 
or by using a leading character symbol, such as $ (which 
is designated as 73 in Fig. 3). When the courtesy 
amount data field has been located, the field is seg- 
mented into individual numeric characters using conven- 
tional character recognition techniques. 

When each character contained in the courtesy 
amount field has been recognized and identified, this 
quantity is compared to the data which was initially 
entered by the customer and is contained in the data 
file in processor 62 for correspondence. If there is 
correspondence, the transaction is proved, and a con- 
firmation is entered into the data file for that docu- 
ment, and then transmitted to verification unit 66d. 

However, if the courtesy amount verification 
processor 70 indicates an error, or fails to verify the 
amount printed on the face of the document, the complete 
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digitized image is displayed to the proof operator on a 
CRT screen at a terminal 74 where the operator visually 
verifies the amount and keys in the correct data to the 
file, or f alternatively, the operator may retrieve the 
5 physical document to verify the amount and correct the 
file. 

A data file having been created which contains 
documents which have all been reconciled, and proof bal- 
ance having been established on all the transactions in 

10 the batch file 60, the documents are physically trans- 
ferred to a second document transport 80, which includes 
a bar code reader 80a, a MICR encoder 80b, and a sorting 
mechanism 80c. As each document is conveyed through 
transport 80, the bar code is read from the document by 

15 reader 80a, and the data associated with that document 
is transmitted to transport 80 from processor 62. The 
amount data received from processor 6 2 is then encoded 
in MICR form on the face of the check by encoder 80b. 
At this point, the documents in latch 60 are sorted by 

20 sorter 80c according to one or more criteria, such as 
the bank upon which the document has been drawn. 

The concept of courtesy amount verification 
can also be applied when using conventional proof and 
encode machines. In this situation, an operator nor- 

25 mally reads bank documents and enters the appropriate 

data via a keyboard • A courtesy amount verification unit 
would read the amount automatically from the document 
(via an image lift unit) to verify that the amount 
entered manually is correct. If there is a discrepancy, 

30 the document record would then be flagged. This flag 

could be used to aid the operator if the batch of docu- 
ments is in an out of balance condition (i.e., to indi- 
cate possible miskeyed documents). 
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CLAIMS 

1. A system for processing financial transactions, char- 
acterized by first processing means (45); first terminal means 
(10), coupled to said first processing means (45), for permitting 
a customer to enter into said first processing means information 
concerning a financial transaction; second terminal means (48), 
coupled to said first processing means (45) for enabling a teller 
to verify said customer-entered information; and first storage 
means (61), coupled to said first processing means (45), for 
storing said customer- entered information subsequent to said 
teller verification. 

2. System according to claim 1, characterized in that 
said customer- entered information is obtained from a plurality 
of documents (44) comprising a transaction, and in that the 
teller verifies said customer- entered information against said 
plurality of documents (44) presented to him by the customer. 

3. System according to claim 2, characterized in that 
said first terminal means (10) includes printing means (22) for 
producing a printed slip (24) of a transaction which slip is pre- 
sented to the teller by the customer. 

4. System according to claim 2, characterized in that 
said first terminal means (10) is adapted to receive each 
document (42), said printing means (22) being arranged to 

encode each document contained within said transaction. 

/ 

5. System according to claim 2, characterized in that 
said second terminal means (48) includes keyboard means for 
correcting any customer- entered information which is deemed 
erroneous. 
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6. System according to either claim 1 or 2, characterized 

by second processing means (62) for receiving said verified 
customer-entered information stored within said first storage 
means (45); document processing means (66) for generating 
information from said plurality of documents (44); and third 
processing means (70) for comparing information generated by 
said document processing means (66) with customer-entered 
information within said second processing means (62) for cor- 
respondence. 



7 - System according to claim 6, characterized in that 
said first and second processing means (45 and 62) are coupled 
by a direct data link or are included within a single computer. 

8 - System according to claim 6, characterized in that 
said first storage means (61) is physically delivered to said 
second processing means (62). 

9 - System according to claim 6, characterized in that 
said document processing means (66) includes reading means 
(66a) for reading information encoded upon each document; 
character recognition means (66b) for reading courtesy amount 
data located on the face of each document; imaging means (66c) 
for producing a facsimile image of the face of each document, 
and second storage means (69) for storing said facsimile image. 

10. System according to claim 9, characterized in that 

information obtained by said reading means (66a) accesses 
customer- entered information within said second processing means 
(62), said accessed information being compared with the data 
read by said character recognition means (66b) for correspondence. 



11. 



System according to claim 10, characterized by display 



0072183 

means (74), coupled to said second storage means (69) and said 
third processing means (70), for displaying said facsimile image 
when said third processing means (70) does not indicate corres- 
pondence, and including keyboard means for amending said 
accessed information within said second storage means (62) to 
attain correspondence. 

12. A method for processing financial transactions within 
a bank, characterized by the steps of enabling a customer to 
enter into a first processing means information concerning a 
financial transaction through the use of a first terminal means; 
enabling a teller to verify and, if necessary, correct the 
customer- entered information by use of a second terminal means; 
and permanently storing within a first storage means said customer- 
entered information subsequent to teller verification. 

13. Method according to claim 12, characterized in that 
the customer obtains the information to be entered from a plu- 
rality of documents (44) which comprise said financial transaction 
and which are presented to the teller by the customer. 

14. Method according to claim 13, characterized by the 
further steps of delivering said verified customer- entered data 
to a second processing means; generating information from said 
plurality of documents; and comparing the generated information 
with said customer- entered information within said second pro- 
cessing means for correspondence. 

15. Method according to claim 14, characterized in that 
the information generating step includes the steps of reading 
information encoded upon each document; reading the courtesy 
amount data located on the face of each document; and producing 

- a facsimile image of the face of each document. 
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